78장. IAM 기본 — User · Group · Role · Policy
이 장에서 말하고자 하는 것
지금까지 우리는 ECS · ALB · RDS · S3 같은 자원을 다뤘다.
그 모든 호출의 뒤에는 같은 질문이 깔려 있다.
“누가, 무엇을, 어디서, 할 수 있는가?”
이 질문에 답하는 시스템이
AWS IAM (Identity and Access Management)
이다.
이 장은 IAM의 4개 핵심 개념을 잡는다.
- User
- Group
- Role
- Policy
1. 가장 큰 그림
누가(주체) → 무엇을(권한) → 어떤 자원에 → 어떤 조건에서
User · Role · Group Policy Resource Condition
IAM은 이 4개 축을 조립하는 시스템이다.
2. User — 사람 또는 머신의 신원
IAM User: 한 사용자
├─ 이름
├─ 비밀번호 / 액세스 키
└─ MFA 디바이스
- 사람 운영자
- CI/CD 시스템 (가능한 한 피하고 Role로 대체)
운영에서는 User 수를 최소화하고
머신 작업은 거의 항상 Role로 풀어야 한다
3. Group — User의 묶음
Group "developers"
├─ User alice
├─ User bob
└─ Policy: S3 읽기, ECS Describe …
같은 권한을 여러 User에게 주려고 만든다.
- 권한은 Group에 붙인다 (User에 직접 안 붙임)
- Group 자체에는 액세스 키가 없다
4. Role — 임시로 빌리는 신원
가장 중요한 개념.
Role: 누구든지 잠깐 빌려 쓸 수 있는 "신분증"
├─ Trust Policy: 누가 이 Role을 받을 수 있나
└─ Permission Policy: 받은 사람이 무엇을 할 수 있나
EC2 · ECS · Lambda 같은 AWS 자원은 거의 Role을 받아서 AWS API를 호출한다.
[EC2 / ECS Task] → Role 받음 → S3 GetObject 가능
- 키를 박지 않는다 (자동 회전되는 임시 자격증명)
- 누가 받았는지 추적 가능
- 외부 계정도 받을 수 있음 (Cross-Account)
5. Policy — 권한의 문서
JSON으로 표현되는 권한 정의.
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": "arn:aws:s3:::msa-uploads/*",
"Condition": {
"StringEquals": { "aws:RequestedRegion": "ap-northeast-2" }
}
}]
}
핵심 5요소:
- Effect — Allow / Deny
- Action — 어떤 호출을 (
s3:GetObject) - Resource — 어떤 자원에 (
arn:aws:s3:::bucket/*) - Condition — 어떤 조건일 때만
- Principal — (Resource-based policy 일 때) 누가
6. 두 종류의 Policy
Identity-based Policy
User · Group · Role 에 붙는다.
"이 사용자/Role은 무엇을 할 수 있나"
Resource-based Policy
자원에 붙는다 (S3 버킷, KMS 키, Lambda 함수 등).
"이 자원에 누가 접근할 수 있나"
S3 버킷 정책 · SQS 큐 정책 · KMS 키 정책이 대표 예다.
7. 평가 순서 — 명시적 Deny 우선
1. 명시적 Deny → 즉시 차단
2. 명시적 Allow → 허용
3. 둘 다 없음 → 묵시적 Deny (차단)
기본은 모든 게 막혀 있고, Allow가 있어야 통과한다
그리고 Deny가 하나라도 있으면 무조건 막힌다
이게 IAM 보안의 기반이다.
8. AWS Managed vs Customer Managed Policy
AWS Managed
AWS가 만들어 제공하는 정책 (예: AmazonS3ReadOnlyAccess).
- 시작에 편하다
- 권한 범위가 넓어 운영에 직접 쓰기엔 과한 경우 많음
Customer Managed
본인이 만든 정책.
- 최소 권한에 맞춰 좁게 작성
- 운영 환경의 표준
AWS Managed는 출발점, Customer Managed가 운영의 자리다
9. 우리 서비스에서
[사람]
├─ IAM User (개발자) ← MFA 필수
└─ Group "developers" → 콘솔 읽기 권한
[머신]
├─ ECS Task Role "orders-task" → orders-db, SQS publish
├─ ECS Task Role "users-task" → users-db
├─ ECS Task Role "payments-task" → payments-db, SQS publish
├─ Lambda Role "thumbnail" → S3 read/write 특정 경로
└─ GitHub Actions Role → ECR push, ECS update (OIDC)
- 사람에게는 최소한의 User
- 머신은 모두 Role
- 각 Role은 자기 일에만 권한
10. 직접 확인해보기 — CLI
User · Group · Role
aws iam create-user --user-name alice
aws iam create-group --group-name developers
aws iam add-user-to-group --user-name alice --group-name developers
aws iam create-role --role-name orders-task \
--assume-role-policy-document file://trust-policy.json
Policy 붙이기
aws iam put-role-policy \
--role-name orders-task \
--policy-name orders-db-access \
--policy-document file://policy.json
“내가 이 작업을 할 수 있나” 시뮬레이션
aws iam simulate-principal-policy \
--policy-source-arn arn:aws:iam::123:role/orders-task \
--action-names s3:GetObject \
--resource-arns arn:aws:s3:::msa-uploads/users/123/x.png
운영 디버깅에 매우 자주 쓴다.
11. 코드로는 이렇게 생겼다 — Terraform
# 사람 그룹
resource "aws_iam_group" "devs" {
name = "developers"
}
# Group에 정책 붙이기 (AWS Managed)
resource "aws_iam_group_policy_attachment" "devs_readonly" {
group = aws_iam_group.devs.name
policy_arn = "arn:aws:iam::aws:policy/ReadOnlyAccess"
}
# ECS Task Role
data "aws_iam_policy_document" "ecs_trust" {
statement {
actions = ["sts:AssumeRole"]
principals {
type = "Service"
identifiers = ["ecs-tasks.amazonaws.com"]
}
}
}
resource "aws_iam_role" "orders_task" {
name = "orders-task"
assume_role_policy = data.aws_iam_policy_document.ecs_trust.json
}
# 좁은 권한 (Customer Managed)
resource "aws_iam_role_policy" "orders_db" {
role = aws_iam_role.orders_task.name
policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Effect = "Allow"
Action = ["rds-db:connect"]
Resource = "arn:aws:rds-db:ap-northeast-2:...:dbuser:orders-db/orders-app"
}]
})
}
12. 이렇게 쓰면 망한다 — 안티패턴
안티패턴 1. EC2 / ECS에 IAM User 키를 박는다
키가 새어 나가면 회수가 어렵고 권한이 그대로 살아 있다.
머신은 Role을 받는다 — 키는 임시 자동 회전
안티패턴 2. 루트 계정으로 일상 작업
루트는 모든 권한을 가진다 — 사고 한 번에 끝.
루트는 MFA 켜고 잠가두고, 일상은 IAM User / Role
안티패턴 3. Action / Resource를 * 로 둔다
“잠깐 안 되네” 의 응급 처치가 영구 권한이 된다.
안티패턴 4. 명시적 Deny를 함부로 쓴다
Deny는 강력해서 의도치 않게 다른 권한까지 막을 수 있다.
가능한 한 Allow를 좁게 — Deny는 진짜 차단이 필요할 때만
13. 한 줄로 정리
IAM은 User · Group · Role · Policy 의 4축이며,
머신은 거의 항상 Role로 푸는 게 운영의 표준이다
14. 이 장의 핵심 정리
- IAM의 4축: User · Group · Role · Policy.
- Role은 임시 자격증명 — 머신 작업의 거의 모든 답.
- Policy는 Effect · Action · Resource · Condition 으로 이뤄진다.
- 평가 순서: Deny가 한 번이라도 있으면 무조건 차단.
- AWS Managed는 출발점, Customer Managed가 운영의 자리.
- 루트는 잠가두고, 일상 작업은 IAM User · Role.